LAYER 1: EXECUTIVE CONTEXT (Cody's Notes)

LAYER 2: CORE PHILOSOPHY (The Narrative Summary)

Gilb's Law—which states that "anything you need to quantify can be measured in some way better than not measuring it"—serves as a vital antidote to the operational paralysis that often plagues software organizations. In technical leadership, it is common to hear the excuse that complex phenomena, such as developer productivity, code quality, or technical debt, are "unmeasurable" because they cannot be captured with absolute mathematical precision. Gilb's Law refutes this mindset by asserting that an approximate, indirect, or proxy measurement is infinitely better than complete decision blindness. It reminds us that measurement is not about achieving perfect truth; it is about reducing uncertainty to make better strategic decisions.

The Tension: Gilb's Law vs. Goodhart's Law

For a technology leader, the art of system design lies in balancing Gilb’s Law with Goodhart’s Law ("when a measure becomes a target, it ceases to be a good measure"). Because leaders are acutely aware of how teams can game metrics (e.g., writing useless tests to boost coverage or closing easy tickets to inflate velocity), they often swing to the opposite extreme: refusing to measure anything at all. This creates a vacuum where gut feel and loudest-voice opinions dominate.

Gilb's Law provides the necessary counterweight. The solution to Goodhart’s Law is not to abandon measurement, but to use metrics for awareness rather than accountability. By combining multiple imperfect indicators and continuously refining them, leaders can gain valuable signals without creating toxic incentives.

Connective Tissue: Outcome Alignment and Value Realization

Under the Technology Operating Model (TOM), Gilb's Law forms the primary connective tissue for Outcome Alignment and Value Realization (Pillar 7). Transitioning from a "Feature Factory" to an outcome-driven organization requires a rigorous focus on value. If a team claims to be working on a project to "improve developer experience" or "optimize performance," they must attempt to quantify it. Refusing to measure because the outcome is hard to isolate results in a lack of accountability. Measuring a proxy variable (such as deployment speed or system responsiveness) provides a baseline for improvement and validates whether the capital invested actually realized the intended business value.

Practical Applications in the TOM

• Measuring Developer Experience and Velocity (Pillar 1): While lines of code or story points are flawed metrics, leaders cannot ignore productivity. Using the DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service) alongside qualitative surveys provides a strong proxy. If deployment frequency drops, it is a signal to investigate pipeline bottlenecks, even if the metric doesn't capture the team's full output.
• Quantifying Technical Debt (Pillar 4): There is no single equation for tech debt. However, tracking a composite of indicators—such as cyclomatic complexity trends, incident rates, and developer survey responses regarding friction—gives leaders a starting point to prioritize refactoring efforts. An approximate map of debt is far better than ignoring it until a major outage occurs.

Generated for the Product Growth Program.

LAYER 3: FULL REFERENCE (Raw Article Content)

Source: Gilb's Law - Laws of Software Engineering

Definition

Anything you need to quantify can be measured in some way better than not measuring it.

Key Takeaways

1. It is better to have some data or metric on a phenomenon than to be completely blind, as long as you understand the metric's limitations.
2. In contrast to Goodhart's Law, which warns about misuse of metrics, Gilb's Law reminds us not to throw out metrics entirely.
3. Start with a basic measure and refine it over time. The act of measuring helps teams focus and identify trends.
4. Even an approximate or indirect measurement is better than none.

Overview

Gilb's Law responds to the paralysis that Goodhart's Law can cause. This law asserts that even an approximate or indirect measurement is better than none. When something is essential (performance, customer satisfaction, code maintainability), you should attempt to measure it, because otherwise you have no objective feedback.

Gilb's Law is a good reply to the statement “this aspect is unmeasurable so we won't try.” For example, measuring “code quality” is difficult, but you can measure indicators such as cyclomatic complexity, lint warnings, or defect rates as partial indicators. More such indicators can paint the bigger picture.

Those metrics won't be perfect, but Gilb's Law suggests that having them gives you some insight and a starting point for improvement, which is better than having no clue at all.

Examples

Measuring developer productivity is notoriously hard (lines of code are poor proxies, story points can be inconsistent). However, you might use deployment frequency or change lead time (as in the DORA metrics for DevOps) as a proxy. They do not capture everything, but they give you actionable data. If deployment frequency decreases, something might be wrong with the pipeline.

Another example is tracking Tech Debt. No perfect measure of tech debt exists. But tracking things like code complexity scores, incident rates, and developer surveys gives you visibility you would not otherwise have. As Peter Drucker said: "We cannot improve what we do not measure."

Origins

Tom Gilb, a consultant and author on software engineering, formulated this law. It complements his other work on quantifying requirements and using metrics in planning, including Planguage and evolutionary project management.

Balance with Goodhart's Law

Gilb's Law and Goodhart's Law form a complementary pair. Goodhart warns against making metrics into targets that distort behavior. Gilb reminds us that avoiding measurement entirely leaves us blind.

The key is to use metrics for awareness, and to continuously refine what you measure

Generated for the Product Growth Program.